Tom, thanks so much for clearing that up.
I think I can button things with regards to the CCoordMotion up now. I will leave things at it is with all public methods exported, but I will only expose the needed ones in the c#dll.
Something that will come up when I start on the Interpreter, but may also be usefull with CoordMotion in non CNC applications-
I want to be able to preview what the motion will do using an OpenGL component I wrote. I typically pre-calculate the geometry separately from motion to display it correctly but I thought it might be cool to have the ability to display exactly what is going to happen by using the same or similar points/segments that are going to be sent to the board.
Do you have any advice for this?
Thank you,
Brad Murry
--- In
DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> See below
>
> --- On Thu, 7/14/11, bradodarb <bradodarb@...> wrote:
>
>
> From: bradodarb <bradodarb@...>
> Subject: [DynoMotion] Additional CoordMotion Comprehension
> To:
DynoMotion@yahoogroups.com> Date: Thursday, July 14, 2011, 6:31 PM
>
>
> Â
>
>
>
> Hello Tom,
>
> Thank you for the detailed response, though I am still a little unclear on a couple things.
>
>
> Please see below
>
>
> Thank you for your patience,
> Brad Murry
>
>
>
> To:
DynoMotion@yahoogroups.com> From: tk@...
> Date: Mon, 11 Jul 2011 23:09:48 -0700
> Subject: Re: [DynoMotion] Coord Motion Callbacks
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi Brad,
>
> See below
>
> --- On Mon, 7/11/11, bradodarb <bradodarb@...> wrote:
>
>
> From: bradodarb <bradodarb@...>
> Subject: [DynoMotion] Coord Motion Callbacks
> To:
DynoMotion@yahoogroups.com> Date: Monday, July 11, 2011, 12:40 PM
>
>
>
>
> Tom,
>
> Before I move on to the interpreter, I want to "button up" what we have so far.
>
> I have a few questions about CoordMotion functions.
>
> Questions for clarification:
>
> What does SetTPParams do?
> This needs to be called whenever Motion Parameters related to the Trajectory Planner have been changed.
>
> What does DownloadDoneSegments do?
>
> Coordinated motion commands such as Straight Feeds and Arcs are initialy added to the Trajectory Planner's segment buffer. As more and more pieces of the path are added the TP can further optimize the motion. Basically as the path lengthens there can be a ripple effect which may effect many earlier segments. At some point the Trajectory Planner can determine segments that can be proven to not be possible to further optimize or change regardless if additional path is added. These segments are flagged as "Done" from a
trajectory planning stand point and are free to be downloaded to KFLOP. This routine will attempt to download those segments to KFLOP motion segment buffer.
>
> So I would use this to limit the possibility of continued optimization for buffered segments?
> No. Actually this function should probably not be exported it is used internally after each linear or arc segment has been added to download whatever is appropriate at that point.
>
> What is DoRateAdjustments?
> The segments in the trajectory planner's buffer have rate (speed) and acceleration limitations. These are computed from constraints of the axes involved and the curvature of motion and such which are in turn a function of the direction of the segment and the angles between segments. In cases where the segments are modified due to other optimizations such as corner rounding and collinear tolerance combining things can change such that the rates
need to be re-evaluated. This function performs that task.
>
> Is this something that needs to be manually done or does TP do this? What are arguments i0 and i1?
> No. Actually this function should probably not be exported it is used internally when ever something has changed that might make it possible or necessary to update the rate constraints. The i0, i1 set the range of segments that need to be considered.
>
>
> What is the diffference between OutputSegment and DoSpecialCommand ?
> Besides downloading motion segments into KFLOP's Coordinate Motion Buffer "Special Commands" can be inserted into the buffer to activate I/O bits and other simple operations. This allows those operations to be executed perfectly synchronized with the possibly continuous motion. This is useful with something like Laser scanning where the beam needs to be switched on or off at an exact point.
>
>
So are "Special Commands" script functions? I am still a little unclear on what OutputSegment is used for. How are integer arguments used here?
> OutputSegment - Actually this function should probably not be exported it is used internally. It downloads the specified segment to KFLOP
> Â
> Yes Special Commands are script functions.
> Â
> Â
>
>
> How is MeasurePointAppendToFile used?
>
> This measures the current x,y,z axes positions and writes it into a disk file. This is used in conjunction with making a geometric correction table.
>
> What does DoKMotionCmd do?
> Any Console Script commands can be embedded into GCode as a special form of comment. These commands are sent to KFLOP when they are interpreted. This routine is used to send the command to KFLOP.
> So I can directly send a console script using this function? Is it
executed imediately?
> Â
> Yes. The second parameter is a boolean that specifies whether to flush the motion buffer. Specifying TRUE will result in all previously specified motion to be trajectory planned, downloaded, and executed before the command is issued. FALSE will issue the command immediately as it is interpreted.
>
> What does DoKMotionBufCmd do?
> Certain commands can be embedded into GCode which are not executed as they are interpreted. Instead they are included into the motion buffer and executed by KFLOP at the same time as the corresponding motion is executed. This routine is used to insert the Buffered Command into the data stream.
> Is this the same as DoKMotionCmd but it places it on the buffer instead of executing immediately?
> Yes, Currently the only supported buffered commands are SetBitBuf, ClearBitBuf, and SetStateBitBuf.
>
>
>
What is the diffference between WaitForSegmentsFinished and
> This routine waits until all the Coordinated Motion Segments have been completely finished
> WaitForMoveXYZABCFinished ?
> This routine waits until a multi axes rapid move is completed
>
> What does FlushSegments do?
> This flushes any remaining coordinated motion segment within the Trajectory Planner's segment buffer that have not been downloaded to KFLOP's Coordinated Motion Buffer
> Based on the Simple CoordMotion example, I should call this every time I am done with the CCoordMotion class?
> Â
> Not really when you are done with the class, but rather to specify the end of a coordinated motion path. Basically the main purpose of the coordinated motion class is to specify coordinated motion paths, some may be short and simple and some may consist of hours of motion.  The assumption is that the path can be
specified and created on average faster than the tool can physically execute the motion. However because we are executing under MS Windows the PC, the trajectory planner, your application etc may possibly freeze for a second or two at any moment so motion must be buffered. As you specify the motion piece by piece the Coordinate Motion library automatically plans what it has been given so far. It also determines when it has enough path that earlier specified path can no longer be influenced by adding additional path. That path can be downloaded to KFLOP's motion buffer. After enough motion has been downloaded to be sure that if a
> momenatry freeze in downloading would occur that KFLOP's buffer would not run dry, the motion is allowed to begin execution. From this point on additional motion will be downloaded as the motion is being consumed. It is usually undesirable to
trajectory plan and download too much motion to KFLOP ahead of the tool because this would result in unnecessary delay in on-the-fly feedrate changes. Linear and Arc calls to add path will automatically block to prevent this. Finally the Coordinate motion library has to be informed that this is the end of the path and that we should come to a stop at the end of the last provided segment. The Library will then finish planning the final motion, download the motion, and begin executing the motion (it it hasn't already started). FlushSegments provides this functionality.
>
> What is the differences between
>
> Abort
>
> Abort causes all motion to abruptly stop usually due to something catastrophic like a communication error
> OK, so stop ASAP- no matter how rough... Good to use for Estop?
> Halt
>
> Halt cause motion to stop in a controlled manner. A feed hold is
commanded so that the motion decellerates along the intended path. After the system completely stops, the exact point in the Coordinated Motion Buffer where the stop actually happened is uploaded and the GCode Interpreter is rewound to that point.
> If just using the CoordMotion and not the interpreter, will a clear Halt resume where it left off?
> Â
> No. If coordinated motion is halted there is some resulting status that may assist you in determining exectly how and where the motion finally stopped. But it is up to the application to create any new motion to resume.
> Â
> To just do a feed hold and resume, there is a mechanism in KFLOP to do this at the hardware level and it has the advantage that it is instantaneous and if an external switch is used it doesn't rely on MS Windows.
>
> and ExecutionStop?
>
>
> Called when the Interpreter is stopping due to
either a single step, a halt, or program stop. If some segments have been downloaded and execution is in progress, then we should send whatever is left in the TP which should bring everything to a safe stop similar as if we had a break angle at this point
>
>
> So this would be the recommended function to call if a user is running a program and they want to press "cancel" or something like that... In other words it will bring everything to a controlled stop without the possibility of resuming?
> No probably poorly named. It is much like FlushSegments to tell the Library that this is it. But besides downloading all the path and such it also blocks until everything is completed.
>
> Sorry for so may questions,
> Sorry for being so confusing, but to include all the necessary functionality of trajectory planning, lookahead, buffering, feedhold, feedrate on the fly, backplotting, halt, resume,
corner rounding, colinear segment reduction, nonlinear kinematics, etc, the code has become very complex and gone through a lot of evolution.
> Â
>
> -Brad Murry
>
> Hope this helps
> TK
>
